home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
The Original Shareware 1.1
/
The Original Shareware (WeMake CDs)(Volume 1.1)(CDs, Inc)(1993).iso
/
30
/
tbscnx29.zip
/
NOTES.TXT
next >
Wrap
Text File
|
1991-06-16
|
13KB
|
245 lines
General notes for TbScan and TbScanX
------------------------------------
TbScan(X) does not mean TurBo-SCAN as some users assume, but stands for
Thunderbyte Scan. TbScan and TbScanX are supplied on the Thunderbyte
disk which makes part of the Thunderbyte hardware PC Immunizer package.
If you loaded TbScanX in video-memory it is possible that TbScan detects
signatures in upper memory. TbScanX does not always scramble the signatures
to gain some speed when it is using (slow) video-memory or expanded memory.
Due to safety routines in the TbScan(X) programs, it can not be compressed
with programs like PkLite, LzExe, or Diet. This is not very painfull
after all because the files aren't that big!
TbScan and TbScanX both need a signature file TBSCAN.DAT or
VIRUSSIG.DAT. Because these files are updated a lot, they are not
supplied with this package. Both of these files are available at
Thunderbyte support BBS +31-85-212395 (2:280/200@fidonet) or at many
other BBSs.
Notes concerning TbScan
-----------------------
Some users think that scanning for all viruses in all files is the best
scanning method (by using "TBSCAN *.* -a +n"). This is not true: It only
increases the possibility of false alarms. It is not usefull to scan for
bootsector viruses in .COM files or to scan for COM viruses in .EXE
files. Use this option only when you already encountered a virus and
want to make sure that you really destroyed all infected files.
If you use the -analyze option, TbScan will issue less warnings. This
is due to the fact that the -analyze option disables the code interpreter
of TbScan. And the code interpreter is the routine that is able to detect
suspicious code. The -analyze option converts the scanner to a normal,
conventional (but also very fast) scanner.
If you run TbScan AFTER you executed another scanner, it is possible that
TbScan finds signatures of viruses in memory. This does not mean that
you have a virus, but is caused by the fact that TbScan detects the
search-signatures left in memory by the other virusscanner.
If you have a disk caching system it is recommended to disable the cacher,
because TbScan will be faster in that case. While TbScan is scanning, the
cacher keeps trying to determine what is going on, storing megabytes of data
in its buffers, but TbScan will read every byte only once, and all clock
cycles spend by the cacher to maintain the data are completely lost!
So, switch that cacher temporary off, it can speed up the operation of
TbScan with up to 20 percent!
Thunderbyte users who have a language file installed should download the
most recent language file, because only the most recent language file
contains the new texts of TbScan.
Notes concerning TbScanX
------------------------
TbScanX is Windows 3.0 aware. It is recommended to load TbScanX BEFORE
starting Windows (even in 386-enhanced-mode). TbScanX will not interfere
with copies of it running in other DOS windows. It is even possible to
disable TbScanX in one window while it is still enabled in another window.
With other words, TbScanX maintains a separate data area for every DOS-window.
If you use a local area network you should invoke TbScanX AFTER the network
software. Otherwise, TbScanX will not be able to detect if a remote file is
being created/opened. In that case TbScanX will only be functional for the
local drives.
Although TbScanX is very reliable, you should regulary use a normal transient
scanner like TbScan, especially after an alarm of TbScanX.
Some people think that we went mad to implement an option to switch TbScanX
off, because viruses can switch off TbScanX too! But, it is not dangerous
at all. TbScanX detects a virus as soon as it is copied to your system,
or before it is being executed. At that time the virus did not have the
opportunity to switch TbScanX off at all! Of course, after the virus becomes
active (and you ignored the first TbScanX warning), the virus could switch
off TbScanX or completely remove it from memory. This applies to all
resident anti-virus software. If you want a real weapon against viruses
that always survives a viral attack we recommend Thunderbyte...
Notes concerning the format of the signature file
-------------------------------------------------
The format of the signature file (also called data file) is covered
completely in the manual on disk. However, there are more scanners using
the same signature file (virscan.dat) as compiled by Jan Terpstra.
Unfortunately, not all scanners use the same format. There is at least one
scanner that has some extensions to the signature file. These extensions
that will not be recognized by TbScan(X) are:
- The virus type identifier "PART" or "MAIN". In my opinion viruses that
infect only the partition table don't exist and will never exist. Why?
Because floppy disks don't have a partition table and are therefore not
suitable to carry such a virus. A virus programmer can be pretty sure
that his/her victims never share and exchange their fixed disks, so his
virus would not reach other systems. So we can conclude that viruses
with the keyword PART should also have the keyword BOOT.
Besides, there are many bootsector viruses that are capable of
infecting partition tables too. The end result is that all signatures with
the keyword PART should also have the keyword BOOT, and that viruses with
the keyword BOOT should also be searched on the partition table,
regardless of the keyword PART. Consider this and you will understand
that in almost all cases the words BOOT and PART are functional equal.
Even if a BOOT virus is not able to infect a partition table there is
no reason why we shouldn't scan for it. There is only one partition table
and it is only one disk sector in size, so scanning speed can not be the
reason. Why then using two or even three synonymous keywords? I don't
know, and I will not implement those keywords.
- The virus type identifier "OVL". Only a few people know that the viruses
that are able to infect overlay files do so by accident, because there
are some linkers that create overlay files which are in reality a kind of
normal EXE file, and these files are also treated that way by DOS. The
virus "thinks" the file is a normal EXE file, and infects it.
The result is that some viruses that infect EXE files are also able to
infect some OVL files, it all depends fully on how their infection
routine is triggered. In my opinion there are no viruses that will ONLY
infect OVL files, because if they do so, they don't have much chance to
spread and they will not survive. Besides, infecting these OVL file is
the same process as infecting a EXE file, so why should the virus writer
add a special routine to prevent EXE files for becoming infected by their
virus? I don't know. The result is that the OVL keyword should always be
paired with a EXE keyword, and that many EXE viruses can accidentially
infect a OVL file. Consider this and you will understand that in almost
all cases the words EXE and OVL are equal. And even if a virus would
infect only OVL files it is not a real pain to search for those viruses
in EXE files too! Anyway, unlike some other scanners, TbScan scans all
OVL files automatically for all EXE viruses. Better safe than sorry!
- The same story applies to SYS and BIN viruses. The only difference
between SYS and BIN files are their extensions, their internal layout
is exactly the same! For reasons beyond my comprehension, the author
of That Other scanner defined two keywords for the same virus type!
Can anybody explain me why it is not a good idea to search for a
BIN marked virus in a SYS file? And if so, why did he omit the
third synonym "DEV"?
- The keyword PIF. I'm not a Windows expert, but I have my doubts whether
a file with the extension PIF contains really any executable code.
- The keyword UMB. The keywords LOW and UMB are actually the same, as I
will explain below in "Notes concerning the scanning of memory". With
the release of DOS 5.00 the keyword UMB becomes obsolete anyway.
TbScan scans automatically the Upper Memory area for all viruses with
the keyword LOW set.
- The XOR brackets '{' and '}'. This "scrambling" technique in its pure
appearance is so seldomly used and so subject to modifications
(mutations!), that this detection scheme is almost useless.
Note that these comments are not intended to anoy the author of "That Other
scanner", nor to give you the impression that his product is less than mine.
In fact, I'm surprised by the speed achieved by that scanner because it has
been created with a high level programming language and is not very much
slower compared to TbScan. I also borrowed some of the ideas implemented in
that scanner. But I have to justify to the users of TbScan(X) why I don't
implement these extensions to the data file. Defining a standard is always
difficult, especially if the developers don't consult each other before
introducing new extensions to the format of the shared input files. :-(
Notes concerning the scanning of memory
---------------------------------------
TbScan recognizes two types of memory signature: LOW memory and HIGH memory
viruses. The keywords are choosen not very carefully: the keyword LOW
means that the virus is a normal TSR-type virus which could reside in
memory below TbScan, and in upper memory. Both locations are suitable for
TSR-type viruses and TbScan will scan both areas for signatures with the
keyword LOW set. The keyword HIGH is intended for boot sector viruses (that
have to allocate their memory by decreasing the available memory value
maintained by the BIOS) and by viruses that allocate memory by manipulating
the DOS memory control block chain.
Consider this layout:
┌──────────────────────────┐ 0Kb
│ │
│ Low memory. │
│ │
LOW │ TSR's are loaded here │
│ │
│ also TSR type viruses │
│ are loaded here. │
├──────────────────────────┤
│ │
N/A │ TbScan is executed here │
├──────────────────────────┤
│ │
│ │
│ Free memory │
HIGH │ │
│ │
│ │
│ │
│ │
├──────────────────────────┤ End of DOS available memory
│ Top loaded software │
HIGH │ like MCB manipulators │
│ and some viruses reside │
│ in this area │
├──────────────────────────┤ 640Kb limit
│ │
│ Video memory │
│ ROM's │
│ EMS page frames │
LOW │ and Upper memory │
│ TSR's (and also TSR type │
│ viruses) can reside here │
├──────────────────────────┤
│ System BIOS │
LOW │ │
├──────────────────────────┤ 1Mb limit
LOW │ HMA │
└──────────────────────────┘
Note that TbScan does not have a special keyword for Upper Memory Viruses.
Viruses that are able to use Upper Memory should also be able to use normal
LOW memory, because they can not rely that there is Upper Memory in every
machine they will reach. Normal TSR-viruses on the other hand can be loaded
in Upper Memory using an appropriate highloader as supplied with Qemm or
even DOS 5.00. So "UMB-type viruses" are the same as LOW viruses!
There is also no need to scan allocated pages of EMS. Viruses can never
reside entirely in expanded memory. They should have at least a piece of
code outside the EMS window, just to have access to the EMS driver to swap
in the correct RAM-pages. By using that piece of code as the search
signature also those (future?) viruses will be found, without the need
to scan all EMS pages.
Some users think it is usefull to scan the memory for all viruses using the
-allmem (+r) option of TbScan. I think it is not a good idea, because memory
signatures are not the same as disk signatures. There are many scrambled
viruses, but in memory they reside unscrambled. The signatures for both
instances of the same viruses could be totally different! The same applies
to signatures that incorporate uninitialized data. In memory the data is
used for some purpose, and the memory values are different. Searching memory
for disk-specific signatures is likely to cause false alarms and the
signatures will not match the memory image of the virus anyway.